The tremendous scalability, flexibility, and speed of Infrastructure-as-a-Service (IaaS) makes it one of the fastest-growing sectors of the cloud computing markets. IaaS providers combine virtualization and containerization technologies with substantial infrastructure to deliver bandwidth, storage, and processing power on-demand and with granular control over scale and costs. The benefits of hosting applications and workloads on cloud servers are enormous, making cloud servers the de facto norm for a rapidly growing set of use cases.
Security and compliance, however, remain major challenges to adoption of public cloud infrastructure services. Usage agreements and documentation squarely make the user of IaaS, not the provider, responsible for protecting servers, applications and data in the cloud—essentially everything from the virtual machine operating system upward, or from the container upward, in the stack.
One challenge to IaaS is that cloud servers attract e-criminals. Online fraud has grown into a sophisticated underground economy that requires infrastructure on a massive scale. Such online fraud comes in many forms, such as phishing, password cracking, and denial of service attacks, and often make use of botnets. Botnets are illicit networks built from compromised servers and personal computers. Some botnets consist of thousands of “zombies,” personal computers infected by malware, which carry out commands on behalf of the botnet operators. These compromised computers can bombard web servers with denial-of-service attacks, fire thousands of password attempts per hour, and participate in numerous other online cracking activities.
Some fraudsters and e-criminals use command-and-control software to coordinate zombie attack execution. Command-and-control software frequently operates from compromised servers, without the server owner's knowledge. Fraudsters demand a constant stream of freshly compromised servers to keep botnets running. An entire underground business known as bot herding has emerged to capitalize on this illicit need.
Bot-herders make their living by building botnets to then sell or rent to other e-criminals. This practice has evolved to the point of Fraud-as-a-Service, the sale of prebuilt botnets on demand, for a few hundred dollars a month. It takes bot herders time and resources to seek out and compromise vulnerable servers. Economies of scale and cost-benefit apply to a bot herding business just as any other. Compromising an elastic cloud infrastructure environment can return a windfall versus hacking into a traditional hardware server. If a bot-herder is able to place command-and-control software on a virtual machine, or a container, that later is duplicated through cloning or cloud bursting, the botnet capacity will automatically grow. For stakeholders in cloud hosting environments, the implication is a higher expectation of being targeted for server takeovers, root-kitting and botnet command-and-control insertions.
An additional security concern for IaaS is that servers have more exposure in the cloud. More specifically, servers hosted in public IaaS environments have more exposure to compromise than servers do within the traditional data center, where layers of perimeter controls defend server weaknesses from exploit. Cloud IaaS environments often do not offer the control over network topology required to implement perimeter security strategies. As a result, vulnerabilities on each cloud server are more exposed to compromise than those in a traditional data center.
In a typical private data center environment, security chokepoints and/or network demarcation zones (DMZs) exist. Firewalls, intrusion detection systems (IDS) and unified threat management devices easily inspect external traffic from sources such as Internet connectivity. Typically, hardware acceleration within the data center boosts performance and compensates for the processing demands required to inspect and control all network traffic in and out of an organization. Because public IaaS environments rarely offer control over hardware or topology, these control mechanisms are unavailable to enterprises hosting servers there.
Traditional perimeter security depends heavily on control over network factors like IP addressing, physical topology and routing. Customers of cloud IaaS have far less of this control; the cloud provider usually dictates network addressing and routing. Server IP addresses are unpredictable, creating serious complications in configuring security mechanisms. Public IaaS environments also typically segment network traffic at the virtual machine level, or the container level, meaning the only traffic a server can see is its own. It is not possible to use network-level intrusion detection systems, intrusion prevention systems or wire-level unified threat management mechanisms in this environment. The performance implications of each cloud server performing traffic inspection at the wire level are staggering, especially given the lack of hardware control. Additionally, the wire-level access to network traffic required of network intrusion detection systems is rarely, if ever, afforded to customers of cloud servers. In multi-tenant cloud environments, such access is impossible since multiple customers share the same network, and allowing access to operate a network IDS would expose multiple customers' network traffic to capture.
Even in a traditional data center with perimeter defenses in place, server-level security such as hardening, secure application configuration, and patch management are important. In the cloud, where front-line defenses are extremely limited, server-level security protection is important. Cloud servers are largely on their own to protect themselves. Strong and highly automated host-based controls that implement all needed capabilities at the host level are important.
An additional security concern for IaaS is that cloud elasticity multiplies attack surfaces. Elasticity is a key differentiator distinguishing IaaS from other infrastructure hosting models. Servers are no longer boxes mounted to racks bolted to the floor. With virtualization, containerization, and cloud technologies, servers are now files and metadata that can be instantly copied, migrated, and stored offline for later reactivation. Uncontrolled copies of virtual servers and their content can be maliciously or accidentally created nearly instantly. Such copies can easily be re-activated in environments also uncontrolled by the server owner. Therefore, only security that is implemented within (and therefore is copied and moves with) a virtual computer, or a container, is able to protect that virtual computer, or container, without regard for its operating location.
Cloud elasticity provides companies with the ability to cloudburst, expanding the number of servers and available computer power within minutes. However, this significantly increases the risk of compromise. The problem is quite simply that, as a virtual server duplicates, so do its vulnerabilities and exposures. Given the speed with which servers can multiply, this issue can increase the attackable surface area of a cloud server farm dramatically within minutes.
Inactive machine images, container images, or snapshots are virtual machines, or containers, that are saved for later reactivation or as a template, or layer, for new servers. While this capability is clearly useful, offline server images, being inactive, do not get updates regarding newly discovered vulnerabilities, policy changes, or modification to user accounts and access rights. When a hibernated server is reactivated, there will be access privileges, software vulnerabilities, and outdated configurations that expose it to immediate compromise.
When adopting a cloud-hosting model, system administrators and other stakeholders should be aware of and account for these issues. One incorrectly configured server, either created recently or resurrected from storage, could multiply during cloning and cloud-bursting operations to become the “typhoid Mary” of the cloud farm.
Another challenge to IaaS arises during development of application code in cloud hosting environments. Many organizations, like small businesses and autonomously-operating business units, turn to cloud hosting for application development. Public cloud hosting reduces barriers to application development, increasing speed to market for technology related products. Special infrastructure skills, network configuration and hardware setup time are minimal. This is an attractive proposition, especially for business and technology managers frustrated with real or perceived delays and “red tape” associated with infrastructure setup. Sometimes central information technology organizations sanction cloud-based development efforts; in some instances, individual business units' charge ahead independently. At some point, all successful development projects go into production. Sometimes the application continues to run in the public cloud environment. Often the application code comes back in-house with the cloud server in a ready-to-run virtual machine image or a ready-to-run container image.
If cloud servers used for development are not secured properly, undesired results may occur. These servers are highly exposed, and often the dynamic nature of application development masks signs of intrusion. Compromise impact could include code theft or insertion of malicious functionality into the new application. Any live data used for development purposes, a poor but disturbingly frequent practice, could be at risk and compromised with the server. If rootkits or other malware are dropped onto the cloud server, that malware could come back to the enterprise data center, making a cloud server into a powerful and dangerous Trojan horse.
As the above background details, clearly there is a new set of exposures and risks associated with hosting applications, data and workloads in public IaaS environments. Existing technologies that secure computers are not adequate at addressing such exposures. For instance, hardware based security devices cannot be used by a virtual machine or a container, because virtual machine and container owners often have no ability to deploy hardware. In many public cloud infrastructure hosting environments, the owner of the virtual machine or container typically has none or limited control over hardware. Server security strategies that depend on creating network perimeter controls are also inadequate because virtual machine or container owners do not have enough control over the networking environment to implement perimeters. Server security strategies that focus on putting security controls at the host level (host-based security) are also ineffective because existing host-based security technologies almost exclusively perform computation on the computer being protected, which consumes large amounts of computing, storage and other resources on each individual computer. Placing multiple host-based security technologies on a single virtual machine, or container, would cause untenable levels of resource consumption on that computer, rendering it unsatisfactory at performing its actual computing function.
The issues above make it clear that improvements in server security management are needed. Specifically, what is needed in the art is the creation of an elastic security management capability for containers and virtual machines that does not impact the performance of the container or virtual machine being protected and is able to implement security controls that move with the container or virtual machine. Conventional perimeter-oriented methods of protection that have worked for years are highly problematic or completely untenable in these environments. The dynamic nature of public and hybrid cloud server farms further complicates matters. The lack of options to protect servers in high-risk public clouds can impede companies from embracing public IaaS and thereby realizing the benefits of IaaS. Thus, there is a need in the art for security measures that secure IaaS servers in an automated, portable, and elastic manner.
The information disclosed in this Background of the Invention section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.